1. Field of the Invention
This invention pertains in general to computer security and techniques for defending against computer viruses and other forms of malicious software, and in particular to detecting and preventing injection of malicious threads into a legitimate process's address space.
2. Description of the Related Art
Software programs executed by modern computers are called “processes.” Each process performs a particular task, such as providing email messaging or supporting a computer peripheral, and a computer can run multiple processes simultaneously. The computer runs each process within its own virtual address space, which allows each process to utilize a large block of seemingly-contiguous memory for its processing. A process can run sub-processes, called “threads,” within its address space.
Some operating systems, such as variants of MICROSOFT WINDOWS, allow a process to read from and write to another process's address space. This functionality is used by certain programs, such as debuggers, where a process executing in one address space needs to gain insight into the operation of a process in another address space. In addition, the ability of one process to read another process's address space allows two processes to share private information without making the information visible to other processes executing on the computer. Some processes, such as those running with high-level security, have restrictions that prevent other processes from manipulating their address spaces. However, most common and frequently-used applications, such as email programs and web browsers, lack any such restrictions on their address spaces.
Unfortunately, allowing one process to manipulate the address space of another process can have negative consequences. A malicious process can use this functionality to compromise legitimate processes. In one attack scenario, a malicious process initially executes unbeknownst to the end-user as part of a Trojan horse, virus, or worm. The process queries the operating system to determine the other processes running on the computer, and identifies a legitimate process that is likely to have network access, such as the web browser. The malicious process next uses the operating system functionality to insert malicious code into the legitimate process's address space and launches the code as a thread of the legitimate process.
Because the malicious thread executes in a legitimate process's address space, it can perform malicious actions that might otherwise be blocked. For example, a firewall can prevent most processes executing on the computer from accessing a network. However, the firewall permits certain processes, such as the web browser, to access the network. The malicious process can thus defeat the firewall by launching the malicious thread in the web browser's address space. Once the malicious thread has network access, it can perform myriad other malicious tasks such as sending confidential information over the network, participating in a coordinated denial of service attack, downloading other malicious software, etc.
There is no easy way for a legitimate process to detect whether a malicious thread is executing in its address space. A process can be configured to periodically check its address space and perform an accounting of the executing threads, but this technique can miss a malicious thread that executes and terminates in the interval between the checks. Another attempted solution relies on using special processes having elevated operating system privileges, such as kernel-mode drivers, to monitor the other processes for malicious behavior. However, there is no guarantee that the operating system vendor will allow third-party processes to execute with the elevated privileges. Other solutions require special code to be loaded into the address space of the process being protected, which can cause unexpected results and/or interfere with the correct operation of the process. Moreover, the malicious process can avoid detection by using obscure function calls or non-standard techniques to launch the malicious thread.
Thus, there is a need in the art for a way to prevent a malicious process from executing a malicious thread in the address space of a legitimate process. Ideally, the solution to this need would not require kernel-mode drivers or other special functionality that might be disallowed or interfere with the legitimate process.